1. Field of the Invention
The present invention relates generally to a management method and system for a wireless communication terminal, and more particularly, to a method and system for remotely managing a wireless communication terminal.
2. Description of the Related Art
A necessity for a standardized method to manage wireless communication devices has developed with the continual increase in the number of wireless communication devices. To meet this need, a Mobile Device Management (MDM) method has been developed, with which wireless operators or service providers can manage Hardware (H/W) functions (e.g., firmware, software, parameter, schedule and capabilities) of each terminal while wirelessly communicating with the terminals. A typical MDM method may include Open Mobile Alliance (OMA) Device Management (DM), as an application standard for wireless communication terminals. OMA DM can manage firmware, software, parameters, and the like in each terminal by reading, adding, deleting, changing and executing objects of a wireless communication terminal using a DM protocol based on Synchronization Markup Language (SyncML). A DM server manages devices such as wireless communication terminals, and the managed devices are considered clients.
The conventional DM method operates on a Peer-to-Peer basis. That is, by creating a one-to-one session between a DM server on the network and a DM client provided in a wireless communication terminal and exchanging messages defined in the DM protocol through the session, the DM server enables the DM client to add/delete/change a particular configuration in the terminal or to perform a particular operation.
The DM protocol is defined by a total of 5 messages: a package #0 to a package #4. A DM session may be formed between a DM server and a device through the DM protocol, and may be initiated by the DM server or by the client, i.e., the device.
FIG. 1 illustrates a conventional DM session setup process.
Referring to FIG. 1, when there is a management operation to perform on a particular device, a DM server 20 informs the device of the existence of a DM action by delivering a package-#10 notification message to the particular device, i.e., a DM client 10 provided in the particular device in step 101. Upon receiving the package-#0 notification message, the DM client 10 makes a request for session setup by sending a package-#1 message to the DM server 20 in step 103. The DM server 20 permits DM session setup, and sends a package-#2 message to the DM client 10 to deliver a DM command for a waiting terminal management operation in step 105. In response to the package-#2 message, the DM client 10 scuds a package 43 message to the DM server 20 to deliver the execution results of the DM command received from the DM server 20 in step 107.
In step 109, the DM server 20 closes the DM session or delivers an additional management operation to the DM client 10 using a package-#4 message, and the DM client 10 performs the additional management operation included in the package-#4 message and reports the results to the MD server 20 using the package #3. Thereafter, the DM server 20 and the DM client 10 may provide management operations or management commands through repetition of the packages 44 and #3. In this case, if a management operation is continuously included in the package-#4 message, the DM session is maintained. However, if there is no additional management operation, the DM session is closed.
In order to take a particular management operation pertaining to the DM client 10, the DM server 20 should know a structure of a DM tree in a wireless communication terminal in which the DM client 10 is installed. The DM tree represents a tree-shaped structure of a Management Object (MO) in the wireless communication terminal, and MO is a means for exposing parameters and objects in the terminal to the DM server 20.
The structure of MO may be defined by an entity such as a service provider and a terminal vendor, and the defined MO structure has an MO IDentifier (ID) that permits identification of its structure. All of MO structures corresponding to MO IDs are registered and managed in a particular server, e.g., an Open Mobile Naming Authority (OMNA), so that an MO structure defined by an entity can be indicated by an MO ID registered in the OMNA. That is, every MO corresponding to one MO ID has the same configuration and structure regardless of the type of the wireless communication terminal.
Among OMA Working Groups, OMA Mobile Broadcast Working Group (BCAST) is specifically, studying a technology standard for providing broadcast services on mobile terminals. OMA BCAST standardizes a service guide, a downloading and streaming technology, a service and content protection technology, and a technology for providing IP-based broadcast services in a mobile terminal environment such as service subscription and roaming.
In line with the trend of the market of providing converged services owing to convergence of the above-described wire/wireless environments, a mobile broadcast technology such as OMA BCAST will also evolve to provide services in the wire/wireless integrated environment beyond the mobile environment.
While a specific example will be described herein below based on an OMA BCAST technology standard, the present invention is not limited to the OMA BCAST technology.
FIG. 2 illustrates a BCAST system of OMA that establishes a standard technology for an application layer and its sub layer or a transport layer regarding a conventional mobile broadcast service, to which the present invention is applied.
Logical entities shown in FIG. 2 will first be described below. A Content Creation (CC) 101 provides contents that are a basis of a BCAST service, and the contents may include common broadcast service files, e.g., movie, audio and video data. The CC 101 provides attributes for the contents, used to generate a service guide and determine a transport bearer over which the service is to be delivered to a BCAST Service Application 102.
The BCAST Service Application 102 receives BCAST service data provided from the Content Creation 101 and processes the received data into a format suitable for media encoding and content protection, and for providing interaction service. The BCAST Service Application 102 provides the attributes for the contents received from the Content Creation 101 to a BCAST Service Distribution/Adaptation 103 and a BCAST Subscription Management 104.
The BCAST Service Distribution/Adaptation 103 performs such operations as file/streaming transmission, service collection, service protection, service guide generation and delivery, and service notification, using the BCAST service data provided from the BCAST Service Application 102. The BCAST Service Distribution/Adaptation 103 also adapts the service to be compatible with a Broadcast Distribution System (BDS) #2 112.
The BCAST Subscription Management 104 manages service provisions such as subscription and charging-related functions of BCAST service users, provisions of information used for the BCAST service, and terminals receiving the BCAST service, on a hardware or software basis.
A Terminal 105 receives contents and a service guide, and information used to support programs such as a content protection program, and provides broadcast services to a user. A BDS Service Distribution #1 111 delivers a mobile broadcast service to a plurality of terminals through mutual communication with the Broadcast Distribution System #2 112 and an Interaction Network 113.
The Broadcast Distribution System #2 112 delivers a mobile broadcast service over a broadcast channel, and an example thereof may include a broadcasting/communication network that is based on Multimedia Broadcast Multicast Service (MBMS) proposed by the 3rd Generation Project Partnership (3GPP), BroadCast MultiCast Service (BCMCS) by 3rd Generation Project Partnership 2 (3GPP2) which is a 3rd generation synchronous mobile communication standard organization, DVB-Handheld (DVB-H) by Digital Video Broadcasting (DVB) which is a digital broadcasting standard organization, or Internet Protocol (IP). The Interaction Network 113 provides an interaction channel, and an example thereof may include a cellular network.
Next, a description will be made of reference points, which are connection paths between the logical entities. The reference points have a plurality of interfaces according to their purpose. Such interfaces are used for communication between two or more logical entities for a predetermined purpose, and a message format and a protocol for the interfaces are applied.
In FIG. 2, BCAST-1 121 is a transmission path for contents and content attributes, and BCAST-2 122 is a transmission path for a Content-protected or Content-unprotected BCAST service, attributes of the BCAST service, and content attributes.
BCAST-3 123 is a transmission path for attributes of the BCAST service, attributes of contents, user preference and subscription information, a user request, and a response to the request. BCAST-4 124 is a transmission path for attributes used for a notification message and a service guide, and keys used for content protection and service protection.
BCAST-5 125 is a transmission path for a Protected BCAST service, an Unprotected BCAST service, a Content-protected BCAST service, a Content-unprotected BCAST service. BCAST service attributes, content attributes, Notification, a service guide a Security material such as Digital Right Management Right Object (DRM RO) and key values used for BCAST service protection, and all data and signals transmitted over a BCAST channel.
BCAST-6 126 is a transmission path for a Protected BCAST service, an Unprotected BCAST service, a Content-protected BCAST service, a Content-unprotected BCAST service. BCAST service attributes, content attributes, Notification, a service guide, a Security material such as DRM RO and key values used for BCAST service protection, and all data and signals transmitted over an Interaction channel.
BCAST-7 127 is a transmission path for service provisioning, Subscription information, and user preference information transmitted over an interaction channel for reception-related control information including a Security material such as DRM RO and key values used for Device Management and BCAST service protection.
BCAST-8 128 is a transmission path over which user data for a BCAST service is interacted. BDS-1 129 is a transmission path for a protected BCAST service, an Unprotected BCAST service, BCAST service attributes, content attributes, notification, a service guide, and a Security material such as DRM RO and key values used for BCAST service protection.
BDS-2 130 is a transmission path for service provisioning, subscription information, and a security material such as DRM RO and key values used for device management and BCAST service protection. X-1 131 is a reference point between the BDS Service Distribution 111 and the Broadcast Distribution System 112. X-2 132 is a reference point between the BDS Service Distribution 111 and the interaction Network 113. X-3 133 is a reference point between the Broadcast Distribution System #2 112 and the Terminal 105. X-4 134 is a reference point between the BDS Service Distribution #1 111 and the Terminal 105 over the broadcast channel. X-5 135 is a reference point between the BDS Service Distribution #1 111 and the Terminal 105 over the interaction channel. X-6 136 is a reference point between the 113 and the Terminal 105.
FIG. 3 illustrates a service guide data model for service guide generation in an OMA BCAST system, or a mobile broadcast system, to which the present invention is applied. This structure has been proposed to provide a broadcast service from a BCAST system to a terminal. One service guide consists of fragments having their own purposes, and the respective fragments are divided into 4 groups according to their uses. In FIG. 3, a solid line connecting one fragment to another fragment indicates a cross reference between the fragments.
As shown in FIG. 3, a service guide data model consists of an Administrative group 200 that provides upper configuration information of the entire service guide, a Core group 220, which is a core part of the service guide, including Service, Content and Schedule, an Access group 230 that provides access information for enabling access to a service or a content, and a Provisioning group 210 that includes subscription and purchase information.
Regarding components of each group, the Administrative group 200 includes. ServiceGuideDeliveryDescriptor 201, and the Provisioning group 210 includes PurchaseItem 211, PurchaseData 212, and PurchaseChannel 213. The Core group 220 includes Service 221, Schedule 222, and Content 223, and the Access group 230 includes Access 231 and SessionDescription 232.
In addition to the above 4 groups, the service guide information includes PreviewData 241 and InteractivityData 251 as shown in FIG. 3. The above-mentioned components are called fragments, which are minimum units constituting, a Service Guide (SG).
The ServiceGuideDeliveryDescriptor fragment 201 indicates information about a delivery session in which a ServiceGuideDeliveryUnit (SGDU) containing fragments constituting the service guide is located, and indicates an entry point for receiving grouping information about the SGDU and a notification message.
The Service fragment 221 is an upper aggregate of contents that are included, in a broadcast service as the core of the entire service guide, and includes content, genre and service area information of the service. The Schedule 222 indicates time information of each of contents included in the service, such as Streaming and Downloading.
The Content fragment 223 includes such information as a detailed description, a target user group, a service area, and a genre of the content being broadcasted.
The Access fragment 231 provides access-related information to enable a user to view the service, and provides a delivery method and session information for the associated access session.
The SessionDescription fragment 232 may be included in the Access fragment 231, and provides location information in the URI form so that the terminal may check information about the SessionDescription fragment 232. The SessionDescription fragment 232 provides address information and codec information for multimedia contents existing in the associated session.
The PurchaseItem fragment 211 helps the user subscribe to or purchase the PurchaseItem fragment 211 by providing service bundles of such factors as content and time.
The PurchaseData fragment 212 includes detailed purchase and subscription information such as price information, promotion information and the like about services or service bundles.
The PurchaseChannel fragment 213 provides access information for subscription or purchase. The ServiceGuideDeliveryDescriptor fragment 201 provides information about an entry point for receiving the service guide, and grouping information for an SGDU that is a container of the fragment.
The PreviewData fragment 241 may be used to provide Preview information for service, schedule and content, or the InteractivityData fragment 251 may be used to provide an interactive service according to the associated service, schedule and content during broadcasting. The detailed information about the service guide can be defined using various elements and attributes for providing detailed contents and values, based on the upper data model in FIG. 3.
While detailed elements and attributes for each fragment of the service guide are not considered in this specification for the sake of conciseness, the detailed elements and attributes do not limit the scope of the present invention described below, and the present invention may be applied to all of the elements and attributes that are defined in providing a service guide for a mobile broadcast service as needed.
As described above, since the conventional device management is achieved between the DM server and the wireless communication terminal on a pear-to-pear basis, it is virtually impossible to restrict terminal functions according to the policy established by the BCAST service provider. Therefore, there is a need for a method capable of controlling terminal functions by delivering the same DM command to a plurality of wireless communication terminals simultaneously according to a policy established by a service provider.